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ABSTRACT 

Functional Reactive Programming, or FRP, is a general frame- 
work for programming hybrid systems in a high-level, declar- 
ative manner. The key ideas in FRP are its notions of be- 
haviors and events. Behaviors are time- varying, reactive val- 
ues, while events are time-ordered sequences of discrete-time 
event occurrences. FRP is the essence of Fran, a domain- 
specific language embedded in Haskell for programming re- 
active animations, but FRP is now also being used in vision, 
robotics and other control systems applications. 

In this paper we explore the formal semantics of FRP and 
how it relates to an implementation based on streams that 
represent (and therefore only approximate) continuous be- 
haviors. We show that, in the limit as the sampling interval 
goes to zero, the implementation is faithful to the formal, 
continuous semantics, but only when certain constraints on 
behaviors are observed. We explore the nature of these con- 
straints, which vary amongst the FRP primitives. Our re- 
sults show both the power and limitations of this approach 
to language design and implementation. As an example of 
a limitation, we show that streams are incapable of repre- 
senting instantaneous predicate events over behaviors. 

1. INTRODUCTION 

How does one show that a language implementation is cor- 
rect? In the programming language research community, 
we normally do this by showing that the implementation is 
faithful, in some formal sense, to an abstract denotational 
or operational semantics of the language. Indeed, if all goes 
well, we can formally derive the implementation from the 
semantics. Such is the nature of "provably correct compila- 
tion." 

However, in the case of Functional Reactive Progamming 
(FRP), a novel language involving continuous time- varying 
values as well as discrete events, the situation is not as clear, 
and several questions arise: 
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1. How does one express the formal semantics of FRP? 
We partially answered this question in a previous pa- 
per [7], and we refine that strategy here. 

2. How does one implement continuous time- varying be- 
haviors? In this paper we explore perhaps the most 
obvious technique, one based on streams that repre- 
sent sampled behaviors (in a signal processing sense). 
However, this representation is only an approximation 
to the continuous values, which leads to the next ques- 
tion. 

3. In what sense is an approximating stream-based im- 
plementation correct with respect to the formal se- 
mantics, and what are its limitations (for example, are 
there values that cannot be represented)? The inter- 
action of these issues with the reactive component of 
FRP makes this especially interesting. 

In this paper we provide answers to all of these questions. 
Specifically, we give a denotational semantics to FRP, and 
show that in the limit as the sampling interval goes to zero, 
a stream-based implementation corresponds precisely to the 
formal semantics, but only with suitable constraints on the 
nature of behaviors. The good news here is that most of the 
common things that we express with FRP programs are well 
behaved, and laws that we expect to hold in mathematics are 
justified, in the limit, when reasoning about FRP programs. 
For example, we can safely apply most FRP primitives, such 
as integration, to behaviors that are discontinuous (in a cer- 
tain way to be described later), which is critically important 
given that the reactive component of FRP creates disconti- 
nuities quite often. 

The bad news is that, since FRP is mathematically very 
rich, many ill behaved values can be expressed. As a result, 
an FRP term does not always have a meaningful seman- 
tics. In such cases we say that the term denotes -L (and 
is thus denotationally equivalent to non-termination or er- 
ror). Of course, this is not very informative. Even worse, 
it is possible to write egregious behaviors for which either 
the implementation does not converge when we increase the 
sampling rate, or it converges to something other than its 
semantics. However, we are able to identify a set of sufficient 
conditions which guarantees the fidelity of the implementa- 
tion. These conditions are neither complete nor decidable 
in general, which means the burden of "good behavior" is 
on the programmer. However, it is perhaps not surprising 
given such a rich mathematical language. 



2. AN INTRODUCTION TO FRP 

In this section we give a very brief introduction to FRP; see 
[5, 7] for more details. FRP is an example of an embed- 
ded domain- specific language [9]. In our case the "host" is 
Haskell [11], a higher-order, typed, polymorphic, lazy and 
purely functional language, and thus all of our examples (as 
well as our implementation) are in Haskell syntax. 

There are two key polymorphic data types in FRP: the 
Behavior and the Event. A value of type Behavior a is 
a value of type a that varies over continuous time. Con- 
stant behaviors include numbers (such as 1 : : Behavior 
Real), colors (such as red : : Behavior Color), and oth- 
ers. The most basic time-varying behavior is time itself: 
time :: Behavior Time, where Time is a synonym for Real. 
More interesting time- varying behaviors include animations 
of type Behavior Picture (which is the key idea behind 
Fran [5, 7], a language for functional reactive animations), 
sonar readings of type Behavior Sonar, velocity vectors of 
type Behavior (Real, Real), and so on (the latter two ex- 
amples are used in Frob [13, 14], an FRP-based language for 
controlling robots). (Note: In our implementation the type 
Real is approximated by Float.) 

A value of type Event a is a time-ordered sequence of event 
occurrences, each carrying a value of type a. Basic events in- 
clude left button presses and keyboard presses, represented 
by the values lbp : : Event () and key : : Event Char, 
respectively. The declarative reading of lbp (and key) is 
that it is an event sequence containing all of the left button 
presses (and key presses), not just one. 

Behaviors and events are both first-class values in FRP, and 
there is a rich set of operators (combinators) that the user 
can use to compose new behaviors and events from existing 
ones. An FRP program is just a set of mutually-recursive 
behaviors and events, each of them built up from static (non- 
time-varying) values and/or other behaviors and events. 

Suppose that we wish to generate a color behavior which 
starts out as red, and changes to blue when the left mouse 
button is pressed. In FRP we would write: 

> color : : Behavior Color 

> color = red 'until' (lbp -=> blue) 

This can be read "behave as red until the left button is 
pressed, then change to blue." We can then use color to 
color an animation, as follows: 

> ball : : Behavior Picture 

> ball = paint color circ 
> 

> circ : : Behavior Region 

> circ = translate (cos time, sin time) (circle 1) 

Here circle 1 creates a circle with radius 1, and the trans- 
lation causes it to revolve about the center of the screen 
with period 277 seconds. Thus ball is a revolving circle 
that changes from red to blue when the left mouse button 
is pressed. 



Sometimes it is desirable to choose between two different 
behaviors based on user input. For example, this version of 
color: 

> color2 = red 'until' 

> (lbp -=> blue) . I . (key -=> yellow) 

will start off as red and change to blue if the left mouse 
button is pressed, or to yellow if a key is pressed. The . I . 
operator can be read as the "or" of its event arguments. 

The function when transforms a Boolean behavior into an 
event that occurs exactly "when" the Boolean behavior be- 
comes True; this is called a predicate event. For example: 

> color3 = red 'until' 

> (when (time >* 5) -=> blue) 

defines a color that starts off as red and becomes blue after 
time is greater than 5. 

Sometimes it is desirable to "lift" an ordinary value or func- 
tion to an analogous behavior. The family of functions 

> liftO : : a -> Behavior a 

> liftl : : (a -> b) -> (Behavior a -> Behavior b) 

and so on, perform such coercions in FRP. Sometimes Haskell 
overloading permits us to use the same name for lifted and 
unlifted functions, such as most of the arithmetic operators. 
When this is not possible, we use the convention of placing 
a "*" after the unlifted function name. For example, >* in 
the color3 example is the lifted version of >. 

Finally, one of the most useful operations in FRP is inte- 
gration of numeric behaviors over time. For example, the 
physical equations that describe the position of a mass un- 
der the influence of an accelerating force f can be written 

as: 

> s,v :: Behavior Real 

> s = sO + integral v 

> v = vO + integral f 

where sO and vO are the initial position and velocity, respec- 
tively. Note the similarity of these equations to the mathe- 
matical equations describing the same physical system: 

s(t) = s 0 + S*v(r)dT 
v(t)=v 0 + J*f(r)dr 

This example demonstrates well the declarative nature of 
FRP. A major design goal for FRP is to free the program- 
mer from "presentation" details by providing the ability to 
think in terms of "modeling." It is common that an FRP 
program is concise enough to also serve as a specification for 
the problem it solves. 

There are many other useful operations in FRP, but we in- 
troduce them only as needed in the remainder of the paper. 



3. THE SEMANTIC FRAMEWORK 

In this section we present the semantic framework for be- 
haviors and events. The semantics of each FRP construct 
will be given individually in Section 6. 

FRP's notion of continuous time is denoted by the domain 
Time, which is a synonym for the set of real numbers K. Let 
(Behavior a ) and (Eventa) denote the set of all FRP terms of 
type Behavior a and Event a respectively, where a is any 
Haskell data type. The meaning of behaviors and events is 
given by the following semantic functions: 

at : (Behavior a ) — » Time Time — ► a 
occ : {Event a ) — > Time — > Time — > [Time x a] 

where [— ] is the list type constructor. 

Intuitively, the meaning of a behavior, as given by at, is a 
function mapping a start time and a time of interest to the 
value of the behavior at the given time of interest. Start 
times relate to the reactive nature of FRP. For example, 
in (6 'until' e), if an event occurrence (t, 6') of e causes 
the overall behavior to switch to b' , we say that b' starts at 
time t. A behavior is unaware of any event occurrences that 
happened before its start time. 

The meaning of an event, given by occ, is a function that 
takes also a start time T and a time of interest t, and returns 
a finite list of time-ascending occurrences of the event in the 
interval (T,t]. The start time of an event is analogous to 
the start time of a behavior. Note that the lower end of the 
interval is open, which means an occurrence precisely at the 
start time is not detected. 

Note that, for simplicity, we have omitted real- world events 
such as user input and general I/O from this semantic frame- 
work. However, predicate events such as described in the 
last section are still present, which are sufficient to demon- 
strate all interesting aspects of the semantics and implemen- 
tation. Nevertheless, for completeness, we describe how to 
add user input in Section 8. 

4. A STREAM IMPLEMENTATION OF FRP 

Our stream-based implementation of FRP is interesting in 
its own right, but because of space limitations we omit a 
detailed discussion of it here; the basic idea is outlined in [6] 
and elaborated in [10]. 

The core data types in FRP, Behavior and Event, are given 
by: 

> type Behavior a = [Time] -> [a] 

> type Event a = [Time] -> [Maybe a] 



Here Maybe a is a data type whose values are either Nothing 
or Just x, where x is some a. 

Intuitively, a behavior is a stream transformer: a function 
that takes an infinite stream of sample times, and yields an 
infinite stream of values representing its behavior. Similarly, 
an event is also a stream transformer, and can be thought 
of as a behavior where, at each time t, the event either 



occurs (indicated as Just x for some x), or does not occur 
(indicated as Nothing). Note that using this implementation 
strategy for events means that we must ensure that the time 
associated with each event occurrence actually appears in 
the time stream, but this is easily done. 

The implementation itself can be divided into two parts: (1) 
definitions of FRP's primitive behaviors, events, and combi- 
nators as stream transformers, and (2) a "run-time system" 
that interprets the behaviors and events by building an infi- 
nite stream of sample times and applying the behavior /event 
to the stream. The latter task is explained in the remainder 
of this section; we return to the former in Section 6. 

To simplify the presentation of the run-time system, we omit 
the interface to the operating system that extracts events, 
grabs the clock time, etc. The resulting abstract implemen- 
tation is captured by the following pair of "interpreters," 
one for behaviors, the other for events: 

at : (Behavior^) — > [Time] — > a 
~ def 

at[b] ts = last {[b\ ts) 

occ : (Event a ) — > [Time] — > [Time x a] 
6cc[e] ts justValues ts ( [ej ts) 

where (1) we write [— J for the value (which could be a 
function) denoted by the Haskell term — , (2) last returns 
the last element of a list, and (3) the auxiliary function: 

justValues : [Time] — > [Maybe a ] — > [Time x a] 

time-stamps a stream of "Maybe" values while dropping the 
"Nothing's." For example, 

justValues [0.0, 0.1, 0.2, 0.3, 0.4] 

[Nothing, Just False, Nothing, Nothing, Just True] 

returns [(0.1, False), (0.4, True)]. 

Intuitively, at takes a behavior and an ordered finite list of 
sample Time's, the first in the list being the start time of the 
behavior and the last being the time of interest. It returns 
as result the value of the behavior at the time of interest. 
Similar is occ, which returns all the occurrences detected 
up until the time of interest. In essence, at and occ define 
an operational semantics for FRP. (Note that 6 is a Haskell 
term of type [Time] -> [a] , so [6 J is a function of type 
[Time] -> [a], and therefore [6 J ts is a value of type [a].) 

In this paper we are most interested in the limit of the op- 
erational semantics as the sampling interval goes to zero. 
Thus we define: 

at* : (Behaviora) — > Time — > Time — > a 

at* [6] T t d = / lim |^ho"*[ 6 l P t such limit exists 
[_L otherwise 

occ* : (Eventa) — > Time — > Time — > [Time x a] 

~*„ „ def flimi „ t i^ n 6cc[e] such limit exists 
occ [e] T t = { \ p t\^° 

[_L otherwise 

where is a partition of [T,t]. 



Definition 1. (Partition and norm of partition) A parti- 
tion P of a closed interval [a, 6] is a non-empty finite list 
[xo,xi, ■ ■ ■ ,x n ], such that a = xo < x\ < ■ ■ ■ < x n = b, 
where n > 0. Such a partition is often written as P*. The 
norm of P, written as |P|, is denned as the maximum of the 
set {xi — Xi-i | 1 < i < n} when n > 1, or 0 when n = 0. 



Time 

The primitive behavior time is implemented as: 



> time : : Behavior Time 

> time = \ts -> ts 



(Note that we overload the notation [a,b] for both a closed 
interval and a list of two elements, and similarly (o, 6) for 
both an open interval and a tuple. However, the meaning is 
always clear from context.) 

5. FAITHFUL IMPLEMENTATIONS AND 
UNIFORM CONVERGENCE 

In the next section we will give both the denotational se- 
mantics and stream-based implementation of each FRP con- 
struct in turn, and show in each case that the implements 
tion is faithful to the semantics, though possibly only under 
certain constraints, in the following formal sense: 

at[b\Tt = at[6] Tt (1) 
occ\e\Tt = occ[e] T t 

In addition, we will identify the cases where the implemen- 
tation converges uniformly, a property (denned below) that 
is necessary to ensure that the integral of a numeric behavior 
is well denned. Analogous to the concept of uniform conver- 
gence for real number function series [1, page 393], we define 
uniform convergence for functions denned on partitions of 
real intervals: 

Definition 2. (Uniform Convergence) Given a set S, we 
say that a function F denned on Vt, which is the set of 
all partitions whose left (i.e. smaller) end is T, converges 
uniformly to / on S if, for every e > 0, there exists a S > 0 
(depending only on e) such that for every t £ 5 and P T 
satisfying \P T \ < 6, 

\F{Pi) - f(t)\ < e 
We denote this symbolically by writing 

F(P T ) >-» f(t) uniformly on S 

So, when possible, we will indicate when the following con- 
dition holds: 



at[b] P T >-> at [6] T t uniformly 



(2) 



Note that (2) implies (1), and for conciseness we will not 
write out (1) if we have already established (2). 

Because FRP is an "embedded" DSL, it is difficult to draw a 
clear line between FRP and Haskell. Thus a full treatment 
of the FRP "language" inevitably requires a treatment of 
all of Haskell. As this would obscure our main interest, we 
choose to discuss only the constructs specific to FRP. 

6. CORRESPONDANCE BETWEEN SEMAN- 
TICS AND IMPLEMENTATION 

The proof of the important theorems in this section can be 
found in appendix A. 



and its semantics is given by: 

at [time] T t = t 

We can show that the implementation of time is faithful to 
its semantics, and that its convergence is uniform: 

Theorem 1. at [time] P T >— > t uniformly on (—00,00). 

Lifting 

Here we show the correctness of the three most useful lift- 
ing operators: liftO, liftl and lift2. The result easily 
extends to any arity of lifting. The lifting operators are 
implemented as: 



> ($*) : : Behavior (a -> b) 

> -> Behavior a -> Behavior b 

> ff $* fb = 

> \ts -> zipWith ($) (ff ts) (fb ts) 
> 

> liftO : : a -> Behavior a 

> liftO x = map (const x) 
> 

> liftl : : (a -> b) -> (Behavior a -> Behavior b) 

> liftl f bl = liftO f $* bl 

> 

> lift2 : : (a -> b -> c) 

> -> (Behavior a 

> -> Behavior b -> Behavior c) 

> lift2 f bl b2 = liftl f bl $* b2 



The semantics of liftO is given by: 

at[lift0 c] T t = |cj 

Unsurprisingly, the implementation converges to the seman- 
tics uniformly: 



Theorem 2. ot[lift0 c] P T 
(—00, 00). 



[c\ uniformly on 



The semantics of liftl is given by: 

at[liftl f bj T t = [f\ (at [6] T t) 

The implementation of liftl is faithful to its semantics, 
but only when the lifted function is continuous: 

Theorem 3. If at [6] T t = bt, and [f\ is continuous at 
bt, then ot* [liftl / 6] T t = [f\ b t . 

It is worth noting that we only require [f] to be continuous 
at bt, not necessarily continuous everywhere. Since most 



functions we deal with in FRP are either globally continuous 
or piecewise continuous, the theorem applies in most cases. 

To see whether the convergence of lif tl is uniform, we need 
a concept called uniform continuity [1, page 74], as found in 
most treatments of calculus: 

Definition 3. (Uniform Continuity) A function / is said 
to be uniformly continuous on a set S if for every e > 0, there 
exists a 5 > 0 (depending only on e) such that if x, y 6 5 
and \x — y\ < 5, then \ f(x) — f(y)\ < e. 

Theorem 4. // at{bj P T m fb{t) uniformly on S, and 
L/J is uniformly continuous, then 

otjliftl / 6] P T >-> L/J (/&(*)) uniformly on S 
For example, the lifted sin function is defined as: 1 

> instance Floating a => Floating (Behavior a) where 

> sin = liftl sin 

Note that the sin on the right hand side of the definition is 
the static version as in the standard Haskell library: 

> sin : : Floating a => a -> a 

As an example, we can use theorem 4 to prove that the 
expression "sin time" in FRP actually denotes the mathe- 
matical notion of sin(t), where t is the current time. 

Corollary 1. at[sin time] P T >— > sint uniformly on 
(-co, co). 

The semantics of lif t2 is given by: 

at[lift2 / b dj T t = L/J (at [6] T t) (at[d] T t) 
Similar to liftl, we can show: 

Theorem 5. If at [6] Tt = bt,at\djTt = d t , and 
(uncurry L/J) is continuous at (bt,dt), then 

at* [lift 2 / b dj T t = L/J h d t . 

as well as the following for uniform convergence: 

Theorem 6. // ot[6] P T >-» fb(t) uniformly on S, 
at[d] P T >— > fd(t) uniformly on S, and (uncurry L/J) is 
uniformly continuous, then 

at[lift2 / b dj P T » L/J (/&(*)) (fd(t)) 
uniformly on S. 

x The instance declaration shown here is how, using Haskell's 
type class system, functions are overloaded. In this case, 
sin is a method in the class Floating, and the instance 
declaration says that sin may now be used for values of 
type Behavior a, for any type a that is already an instance 
of the class Floating. 



For example, we can use this theorem to verify the semantics 
of the lifted binary operator +: 

> instance Num a => Num (Behavior a) where 

> (+) = lift2 (+) 

Corollary 2. at* \b + dj T t = at* [6] T t + at\d\ T t 

Integration 

We use a very simply numerical algorithm to calculate the 
Riemann integration of numeric behaviors: 



> integral : : Behavior Real -> Behavior Real 

> integral fb = 

> \ts@(t:ts I ) -> 0 : loop t 0 ts' (fb ts) 

> where loop tO acc (tl:ts) (a: as) 

> = let acc 1 = acc + (tl-t0)*a 

> in acc 1 : loop tl acc 1 evs ts as 



The formal semantics of integral is given by: 

at [integral f] T t = J (at[/] T t) dr 

As mentioned earlier, this stream-based integrator is only 
sound mathematically if the behavior to be integrated con- 
verges uniformly: 

Theorem 7. // at[6] P T >-» fb(r) uniformly on [T,t], 
then 

otjintegral 6] P T >-» J fb(n) di] 
uniformly on [T, t] . 

If at [6] Pf >— > fb(r) non-uniformly, we can say nothing 
about at [integral 6] T t. As an instance, consider the 
behavior bizarre (inspired by [1, page 401]), which is non- 
uniformly convergent on [0, 1], and is defined as: 

> bizarre : : Behavior Real 

> bizarre = 0 'until' e ==> b 

> where e = when (time >* 0) 'snapshot' time 

> b = \(_,tl) -> c*c*time*(l - time)**c 

> where c = 1/tl 

On time interval [0, 1], the above is equivalent to: 

> bizarre = \(t0:tl:ts) -> 

> 0:0: map (let c = l/(tl - tO) 

> in \t -> c*c*t*(l - t)**c) ts 

When t G [0, 1], we have 

at [bizarre] 0 t 
= lim| p j /ast (LbizarreJ Pq) 

= limjpji^g c 2 t(l — t)°, where 

1/c = the length of the first sub-interval of Pq 

= 0 



Hence J* (at* [bizarre] 0 tj dt = 0. However, we have 

at [integral bizarre] 0 1 

= "m| Po i ho E? = i (Lbizarrej P 0 1 ) ( . ) • At, 

where Pq = [to = 0, ti , . . . , t„ = 1], and 
subscript ^ means the i-th element of a list 

= lim |pi|_ >0 S"=2 c2 *<-i( 1 -<»-i) C ' A *», 
where c = 1/Ati 



and 



lim 

c— >oo 



f c 2 t(i-ty 

Jo 



dt = lim 



oo (c+ l)(c + 2) 



= 1 



Therefore 



at [integral bizarre] 0 1 

^ J (<*** [bizarre] 0 t) dt 

In other words, the limit of the integral doesn't agree with 
the integral of the limit for bizzare. 

It turns out that global uniform convergence is usually too 
strong a condition to achieve in practice, part of the reason 
being that the interplay of behaviors and events often re- 
sults in _L at the point of behavior switching. The following 
theorem relaxes the requirement considerably: 

Theorem 8. If at\b\ Pf >-» fb(r) uniformly on [T,t], 
except at n (finite) points n, t 2 , ■ ■ ■, t„, and at[6] P^' is 
bounded as \P^ \ — > 0 for every 1 < i < n, then 

ot[integral 6] f£ >-» J F(rj) drj 
uniformly on [T,t], where 

J fb(i]) V 7^ Tifor every! < i < n 



F(n) = 



[any finite value otherwise 



Since most behaviors we encounter in practice are bounded 
on every finite interval, the above condition is not hard to 
satisfy. 

As shown in theorem 7, integration preserves the uniform 
convergence property. This allows us to safely calculate the 
second integral, the third, and so on: 



Corollary 3. If at\b\ Pf >— > fb(r) uniformly on [T,t], 
then 



ot[ integral (integral ...(integral &)...)] 

>-> / / . . . / fb(r„) dr„ dr n -i . . . dn 
Jt Jt Jt 

uniformly on [T, t] . 

Event Mapping 

The ==> operator essentially maps a function over the event 
stream, and is implemented as: 



> (==>) : : Event a -> (a->b) -> Event b 

> fe ==> f = map (map f) . fe 

Its semantics is given by: 

occ[e ==> /] T t = 

[(ti,L/J (<2, L/J v 2), ■ ■ ■ , (in, L/J ■"„)], where 
occ[e] T t = [(ti,vi), (t 2 ,v 2 ), . . . , (t„,v„)] 

Theorem 9. Ifocc\e\ T t = [(ti,ui), (t2,v 2 ), ■ ■ ■ , (t„,v„) 
and [/J is continuous at Vi for every 1 < % < n, then 

occ [e ==> /] T t = 

[(tl,L/J Wl),(t2,L/J «2)> ■ ■ ■ > (*n, L/J «»)] 

The -=> operator we used previously is just syntactic sugar: 
e -=> b d = e ==> \_ -> b 

Choice 

. I . can be used to merge two events of the same type; it is 
implemented as: 

> ( . I . ) : : Event a -> Event a -> Event a 

> f el . I . f e2 = 

> \ts -> zipWith aux (fel ts) (fe2 ts) 

> where aux Nothing Nothing = Nothing 

> aux (Just x) _ = Just x 

> aux _ (Just x) = Just x 



The semantics of . I . operator is given by: 

If occ[ei] T t = [(ti, vi), (t 2 , v 2 ), . . . , (tn, v n )], occ[e 2 ] T t = 
[(t'i,v'i), (t2,v' 2 ), . . . , (t' m ,v' m )], andti,t 2 , . . . , t n , t[, t 2 , . . . ,t' m 
are distinct, then 

occ[ei . |. e 2 ] T t = [(n, wi), (t 2 , w 2 ), . . . , (r„ +m , w n+m )], 

where ts = {ti,t 2 , . . . ,t n ,ti,t' 2 , . . . , t' m ], and 

(tj,Vj) tj is the i-th smallest of ts 



(n,wi) 



(t' k ,v' k ) t' k is the i-th smallest of ts 



Note that we require the occurrence times are distinct, be- 
cause the result of merging two simultaneous occurrences is 
nondeterministic. 

We can show that the implementation of ( . I . ) converges 
to its semantics. To save space, we don't give the formal 
statement here. 

Behavior Switching 

The until operator is implemented as: 

> until : : Behavior a -> Event (Behavior a) 

> -> Behavior a 

> fb 'until' fe = 

> \ts -> loop ts (fe ts) (fb ts) 

> where loop ts@(_:ts') "(e:es) (b:bs) = 

> b : case e of 

> Nothing -> loop ts 1 es bs 

> Just fb 1 -> tail (fb 1 ts) 



and its semantics is given by: 

If occ[e] T t = [(ti, |6iJ), • • • , (t„, [b n \)], then for any r £ 
[T,t], 



at [6 'until' e] T t = 



at [6] Tt n = 0 or t < ti 
at[6i] ti t otherwise 



This operator is precisely where behaviors interact with events, 
and thus its good behavior is critical to the goodness of FRP. 
We can show: 



Theorem 10. Ifocc"\e\ Tt = [{ti,[bi\), . . . ,{t n ,[b n \)], 
then for any t £ [T, t] where t ti , 

at* [h 'until' e] T t = 

\at\b~\ T t n = 0 orr <ti 

j lim^^ti at [6i] ij t otherwise 



Most behaviors are continuous with respect to their start 
times (i.e. a small change in the start time only results in 
a small change in the result value); for example this is true 
of integral. Some behaviors are even independent of the 
start time, as with time. In such cases, the limit operator in 
the above theorem can be dropped, and the implementation 
becomes consistent with the semantics. 



> when : : Behavior Bool -> Event () 

> when fb = 

> \ts -> zipWith up (True : bs) bs 

> where bs = fb ts 

> up False True = Just () 

> up _ _ = Nothing 

We define the semantics of when as follows: Given T,t £ 
Time, let fb(r) = at [6] T t. If there are ci , C2 , • • • , Cn £ 
Bool and a partition [to,ti, ■ ■ ■ ,t n ] of [T,t], such that: 

1. For all 1 < i < n — 1, a = ->Cj+i; 

2. For all 1 < i < n — 1, t £ (tt-i,tt) implies /6(t) = a; 

3. fb(T) ^ _L or ci = False, and 

4. fb(t) ± J_ or c„ = True. 

then occjwhen 6] T t = occs _L, where occs is the shortest 
time-ascending list satisfying: 

1. If ci = True and fb(T) = False, then (T, ()) £ occs; 

2. For 1 < i < n — 1, (ti, ()) £ occs if c, = False, and 

3. If c n = False and fb(i) = True, then (t, ()) £ occs. 



Snapshot 



snapshot samples a behavior at the exact moments an event 
occurs. 



> snapshot : : Event a -> Behavior b 

> -> Event (a,b) 

> snapshot fe fb 

> = \ts -> zipWith aux (fe ts) (fb ts) 

> where aux (Just x) y = Just (x,y) 

> aux Nothing _ = Nothing 



The semantics: 

If occ[e] T t = [(ti , oi), (t 2j o 2 ), • • • , {t n , a n )] and at [6] T U = 
bi, then 

occ[e 'snapshot' 6] T t = 

[(ti, (ai,6i)), (t 2 , (02,62)),..., [t n , (a„,b„))] 

The implementation is faithful to the semantics uncondi- 
tionally: 



Theorem 11. If 6cc[e} T t = [(t u ai), (t 2 ,a 2 ), . . . , 
(t n ,a n )] and at [6] T U = bi, then 

occ* [e ' snapshot ' b\ T t = 

I (t 1 , (ai , 61 )) , (t 2 , (a 2 , 62)) , ■ ■ ■ , (t n , (a„ , b„ )) ] 

Predicate Events 

We can turn a Boolean behavior into an event that occurs 
every time the behavior changes from False to True. To do 
so we use the when combinator defined as: 



Otherwise occ [when 6] T t = _L. 

This may seem complicated, but it basically says that when b 
has an occurrence at time t iff at [6] T r\ (viewed as a func- 
tion of rj) jumps from False to True as rj crosses point t 
from the left (i.e. the negative side). 

According to this rule, if fb(r) toggles its value back and 
forth instantaneously at some To £ (T,t), then 
occ[when 6] T t = _L. To see why this is true, suppose 
occ[when fc] T < / 1, then there must be ci,...,c„ and 
to, • • • , t n satisfying the above constraints. In addition, to 
must be equal to tk for some 1 < k < n — 1, because fb(r) 
remains constant in each of (tj-i, ti) where 1 < i < n. How- 
ever, this means cu = c^+i , which violates the constraint 

Ci = -iCj+l. 

This rule implies that on any finite time interval, a predicate 
event can only occur a finite number of times (for the num- 
ber n above is finite). Therefore, if the Boolean behavior 
ever oscillates at an infinite frequency (we will see such an 
example later), the semantics of the event is _L. 

The implementation of when b is faithful to the semantics if 
the implementation of b converges uniformly: 

Theorem 12. Given a time interval [T,t], if at[b] Ft m 
fb(j) uniformly on [T,t], then 

occ* [when 6] T t = occ[when 6] Tt. 



We require at[b] Pt ^> fb{r) uniformly on [T,t], because 
the meer existence of at [6] T r is not sufficient here. For 



example, given the behavior bizarre we discussed in Section 

6, at [bizarre >* 1] 0 t = False for every t 6 [0, 1], and 
thus occ[when (bizarre >* 1)] 0 1 = [], but 

5cc [when (bizarre >* 1)] 0 1 = [(0, ())] ^ [] 

7. EGREGIOUS BEHAVIORS AND EVENTS 

As mentioned earlier, it is possible to define certain egregious 
behaviors and events in FRP, and a good understanding 
of them is helpful in understanding the semantic rules and 
theorems that we have introduced. Consider first this event: 

> sharp : : Event () 

> sharp = when (time ==* 1) 

This looks innocent enough, but the predicate is true only 
instantaneously at time = 1. To sample sharp, let's con- 
sider a series of partitions {P n \ n 6 N} of [0, 2], where P„ = 
[°'2^T'2^T---fST' 2 ]- Obviously lim^oo \P n \ = 0, 
however none of the partitions divides [0, 2] at point 1. Hence 
our sampling based implementation could fail to find the 
event occurrence at time 1. This explains why our semantic 
rule for when gives J_ as the denotation of sharp. 

It is worth pointing out that one can write a well-behaved 
definition for sharp: 

> sharp2 = when (time >=* 1) 

Consider next this encoding of Zeno's Paradox: 

> zeno : : Event () 

> zeno = when (liftl f time) where 

> f t = t < 2 && even (floor (log2 (2 - t))) 

This example demonstrates an infinitely dense sequence of 
events at times to = 1, ti = 1.5, £2 = 1.75, and in gen- 
eral t n +i = t„ + 2~( n+1 \ This creates obvious problems 
with an implementation. But even if we could implement 
such event sequences, there is a more fundamental semantic 
problem. Suppose there is an electric light in a room, ini- 
tially off. A daemon comes in and turns the light on at time 
to, off at time t\, and so on. A simple calculation shows that 
lim^-joo t n = 2, so the whole process comes to an end at time 
t = 2. Now the question is: is the light on or off after the 
daemon stops? The answer might be surprising: it could be 
either on or off; i.e., this is a natural expression of nondeter- 
minism. Our semantic rules give that occ[zeno] T t = ± for 
any T < 2 < t, which provides no information about what 
the implementation will give us, and therefore is compatible 
with the nondeterministic semantics one might expect. 

Finally, consider this unpredictable behavior: 

> unpredictable : : Behavior Real 

> unpredictable = 

> 0 'until' (when (time >* 1) 

> 'snapshot' sin (l/(time - 1)) 

> ==> (\(_,x) -> liftO x)) 



In a stream-based implementation, we don't know what 
value unpredictable will yield at run time, since it depends 
on the sampling frequency and phase. For this example, the 
semantic rules give a value in terms of sin j^j where t = 1, 
which is undefined due to the discontinuity of the function. 

sharp, zeno and unpredictable are all examples where the 
semantics is _L. There are other egregious values where the 
semantics is not _L, but the implementation does not agree 
with it. integal bizarre is one of them. 

8. INTERFACE WITH REAL WORLD 

As was mentioned earlier, behaviors and events can also re- 
act to user actions, which we can capture formally through 
the notion of an environment, which can be viewed as a fi- 
nite set of primitive behaviors and events. Thus, strictly 
speaking, the semantic functions should have type: 

at : (Behavior a ) — > Env — > Time — > Time — > a 
occ : {Eventa ) — > Env — > Time — > Time — > [Time x a] 

where Env is the abstract data type for all the input to the 
FRP system. 

For example, in Fran, the environment includes mouse move- 
ments, mouse button presses, and keyboard presses. Thus 
we can define Env = PBehi^t x int x PEvtQ x PEvtg x 
PEvt Chsr , where the four components of the tuple correspond 
to mouse position, left button press, right button press and 
keyboard press, respectively. Type of the form PBeh a and 
PEvta are defined as: 

PBeh a = Time — > a 

PEvt a = Time —> [Time x a] 

This idea can be justified by noting that primitive behaviors 
and events are in fact observations of physical signals outside 
of the FRP system. Their values at a particular time do not 
depend on when we start the observation. Therefore a value 
of type PBeha is just a mapping from the current time to 
the value, and a value of type PEvt a is a mapping from 
current time to all the occurrences since the initialization of 
the system. 

The treatment of environment is almost orthogonal to the 
treatment of the individual FRP operators. This allows us 
to address the issue separately. To extend the stripped-down 
version of FRP to incorporate environments, we need only 
to: 

1. Define the semantics for the FRP constructs that rep- 
resent user actions. 

For mouse :: Behavior (Int, Int), we have: 

at[mouse] (mouse, lbp,rbp, key) T t = mouse t. 
For lbp :: Event (),wehave: 

occ[lbp] (mouse, lbp, rbp, key) T t = after T (lbp t), 

where after T list drops all elements in list whose 
time-stamp is less than or equal to T. 

2. Pass the environment parameter around in the seman- 
tic equations for composite behaviors/events. For in- 



stance, the meaning for lif t2 is now given by: 

at [lift 2 / bi b 2 ] env T t = 

L/J (at [61] env T t) (at [62] env T t) 

9. CONCLUSIONS AND RELATED WORK 

Although the signal processing literature is full of founda- 
tional work on the validity and accuracy of sampling tech- 
niques, we are not aware of any work attempting to define 
the semantics of a reactive programming language such as 
FRP. Also, most of the signal processing work shies away 
from discontinuous signals, whereas we have shown that un- 
der the right conditions values are still well behaved. 

In [7] we described a denotational semantics for Fran. The 
semantics given in this paper is different in that it parame- 
terizes the start time for behaviors and events, and contains 
a more precise characterization of events. Various imple- 
mentation techniques for Fran are discussed in [6], including 
the basic ideas behind a stream-based implementation; in 
[10] the particular implementation used in this paper is de- 
scribed in detail. 

It is worth noting that we concentrated here on just one im- 
plementation technique for FRP; it may well be that other 
techniques either have more or fewer constraints than those 
discovered for streams. In particular, it is worth pointing 
out that interval analysis can be used to safely capture in- 
stantaneous predicate events [6, 7]. 

Finally, we point out that all of our results depend on suffi- 
cient accuracy of the underlying number system implemen- 
tation. In the limit, of course, that requires an implementa- 
tion of exact real arithmetic. Numerical analysis techniques 
are ultimately needed to ensure the stability of any system 
based on floating-point numbers. 

CML (Concurrent ML) formalized synchronous operations 
as first-class, purely functional, values called "events" [15]. 
Our event combinators ". I ." and "==>" correspond to 
CML's choose and wrap functions. There are substantial 
differences, however, between the meaning given to "events" 
in these two approaches. In CML, events are ultimately used 
to perform an action, such as reading input from or writing 
output to a file or another process. In contrast, our events 
are used purely for the values they generate. These values 
often turn out to be behaviors, although they can also be 
new events, tuples, functions, etc. 

Concurrent Haskell [12] contains a small set of primitives 
for explicit concurrency, designed around Haskell's monadic 
support for I/O. While this system is purely functional in 
the technical sense, its semantics has a strongly imperative 
feel. That is, expressions are evaluated without side-effects 
to yield concurrent, imperative computations, which are ex- 
ecuted to perform the implied side-effects. In contrast, mod- 
eling entire behaviors as implicitly concurrent functions of 
continuous time yields what we consider a more declarative 
feel. 

Several languages have been proposed around the synchronous 
data-flow notion of computation. The general-purpose func- 
tional language Lucid [16] is an example of this style of lan- 
guage, but more importantly are the languages Signal [8], 



Lustre [4], and Esterel [2, 3] which were specifically designed 
for control of real-time systems. In Signal, the most funda- 
mental idea is that of a signal, a time-ordered sequence of 
values. Unlike FRP, however, time is not a value, but rather 
is implicit in the ordering of values in a signal. By its very 
nature time is thus discrete rather than continuous, with 
emphasis on the relative ordering of values in a data-flow- 
like framework. The designers of Signal have also developed 
a clock calculus with which one can reason about Signal pro- 
grams. Lustre is a language similar to Signal, rooted again 
in the notion of a sequence, and owing much of its nature 
to Lucid. 

Esterel is perhaps the most ambitious language in this class, 
for which compilers are available that translate Esterel pro- 
grams into finite state machines or digital circuits for em- 
bedded applications. More importantly in relation to our 
current work, a large effort has been made to develop a for- 
mal semantics for Esterel, including a constructive behav- 
ioral semantics, a constructive operational semantics, and an 
electrical semantics (in the form of digital circuits). These 
semantics are shown to correspond in a certain way, con- 
strained only by a notion of stability. 
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APPENDIX 

A. PROOF OF THEOREMS 

We first point out the following useful property that every 
behavior and event observes: 

Definition 4- (n-equality) Given an integer n and two 
lists h and fa, if 

length h > n, length fa > n, and 
take nl\ = take n I2, 

then we say that fa and fa are n- equal, which we write as 
ii = fa- 



Lemma 1. For any b 6 (Behavior a ) , e 6 {Event a ), ts,ts' 6 
[Time], and n £ N, ts = ts' implies that: 

\b\ ts = [b] ts' , and 
[e\ ts = [ej ts' ■ 

This Lemma essentially says that the current value of a be- 
havior or event does not depend on the future. The proof 
of this lemma is an induction on the syntactic structure of 
an FRP expression. 



Lemma 2. [liftlj f b ts = map f (b ts). 



Proof. 



[liftlj f bts 

([liftOj / [$*J b)ts (definition of liftl) 
(Xts.zipWith [($)J ([liftOj f ts) (b ts)) ts 

(definition of $*) 
zipWith [($)J ([liftOj fts)(bts) 
zipWith [($)J (map (const f) ts) (b ts) 

(definition of lif tO) 
map f (b ts) 



□ 



Lemma 3. [lift2j / 61 62 ts = zipWith f (bi ts) (62 ts). 
The proof is not hard and omitted. 

Theorem 1 

Proof. For any e > 0, let d = 1, for any P T such that 
\P T \ < 5, we have 

at[time] P T 

= last ([time J P T ) (definition of at) 

= last P T (definition of time) 

= t 

Hence | at [time] P T - t\ = 0 < e. □ 

Theorem 2 

Proof. For any e > 0, let d = 1, for any P T such that 
\Pt\ < S, we have 

ot[lift0 c] Pt 
= last ([lif tO cj P T ) 
= last ([liftOj [c\ P T ) 

= last (map (const |_cj ) P T ) (definition of lif tO) 

= LcJ 

Hence | at [lif tO c] P T - [cj | = 0 < e. □ 

Theorem 3 

Proof. 



bt = lim at [6] P T 



Thus 



L/J bt 

= L/J ( lim at[6] P T 
VKho , 

= lim L/J (at[6] P T ) 

(L/J is continuous at lim| pt ^atlfe] P T ) 
lim L/J {last (L&J P T )) 



lim last (map L/J ([b\ P T )) 
\ p t\->° 

lim last (LliftlJ L/J W Pt) 

(lemma 2) 
at" [lift 1 fbjTt 



n 

lim V fot[/] ?i) ■ AU 



I T I i = l 

Furthermore 



□ 



Theorem 4 

Proof. For any e > 0, since L/J is uniformly continuous, 
there is an rj > 0, such that for any u, v', \v — v'\ < n implies 

I L/J « — LfJ 

Since at[6] Pf >— > /&(£) uniformly on 5, for the above 77, 
there is a S > 0, such that for every t 6 5, |Pf| < <5 implies 
|ot[6] Pt-/6(*)| <»?■ 

Hence for every t £ 5, \P T \ < $ implies 

|ot[lif tl fb\P T - L/J (/6(*)) I 

= I L/J (£*[&] J4) - L/J (/&(*))! 



< e 



□ 



Corollary 1 

Proof. Since 

at [time] Pt >— > t uniformly on (— oc, oc) 

(by theorem 1), and Ls±nJ = sin is uniformly continuous, we 
have 

at[liftl sin time] P T >— > sint 
uniformly on (—00,00) (by theorem 4). 

According to the definition of lifted sin: 



> instance Floating a => Floating (Behavior a) where 

> sin = liftl sin 



we have 

at[sin time] P T >— > sint uniformly on (—00,00). 

□ 

Theorem 7 

Proof. For any r G [T,t], 

lim at[integral f] Pf, where Pf = [to,ti, . . . , t n ]. 

= lim last (Lintegral /J P T ) 

\ p t\->° 

n 

= lim V ([/J P?) ... ■ AU, where At 4 = U — 
(definition of integral) 

n 

= lim Vfioat fL/J^O) ' At i> 

where Pj = tafte i Pf . (lemma 1) 



lim ^ (ai[/] fl) ■ AU - / (it* [/] T dq 

n 

lim V fai[/] Pt) ■ AU- 

n 

lim V fai'l/] Tti) -At* 

n 

lim V (at[fj Pi - at if} T ti) ■ At 

< lim y^ei-Atj, 

where e 4 = |at[/] P - at*[/] T tJ . 



Since at[/] Pf >— > at [/] T t uniformly converges on [T,t], 
for every given e > 0, there is a 5 > 0, such that as long as 
\P£\<6, 

e, < e, for every 1 < i < length Pt- 
Thus when |Pf | < 5, for every t 6 [T, t] we have 

n n 

^ej-Atj < ^e-Ati = e-(r-T) < e ■ (t - T) 

i=l i=l 

Since e is arbitrary, at[integral /] Py uniformly converges 
to /; (at* [/] Ti,)di,. □ 

Theorem 10^ 

Proof. If occ* [e] T t = [], then there is a S > 0 such that 
for every partition P T of [T, t] where |Py| < 5, 
justValues P T ([e\ P T ) = []• Therefore 

lim last (lb 'until' ej P T ) 
= lim Jast (161 P T ) 

\ pt T h° 

(definition of until) 
= at\b\Tt 



If occ*[e] T t = [(ti, |6iJ), • • • , (t m , L6mJ)], where m > 0, 
then for a partition P = [rjo, 7ji, . . . , 7j n ] of [T, t], when |P| 
is small enough, justValues P ( [ej P) will have m ele- 
ments. Let the first of the m elements be (7;^, L&'J); and 
pk = [Vk j Vk+i ,■■■,»?«], then 

lim /ast (16 'until' el P) 

|P|-»0 

= lim /ast (l&'l P*) 

(definition of until) 
= lim at* [61] i] t 



□ 



